The Evolved Packet System (EPS), which is the successor of GPRS (General Packet Radio System), provides new radio interface and new packet core network functions for broadband wireless data access. Such EPS core network functions are the Mobility Management Entity (MME), Packet Data Network Gateway (PDN-GW) and Serving Gateway (S-GW). FIG. 1 shows a schematic overview of the EPS architecture, as described in [1].
A common packet domain Core Network is used for both Radio Access Networks (RAN) the GERAN and the UTRAN. This common Core Network provides GPRS services.
For Machine-Type-Communication (MTC) a new functional entity called MTC-IWF (interworking function) and some new interfaces (S6m, Tsp, Tsms, T5a/b/c and T4) were introduced to the 3GPP architecture. FIG. 2 shows a schematic overview of the 3GPP architecture for Machine-Type-Communication, as described in [2].
Main purpose of the MTC-IWF and the new interfaces in 3GPP Release 11 is to enable triggering of devices (e.g. in order to establish a PDN (Packet Data Network) connection/PDP (Packet Data Protocol) context) with or without MSISDN (Mobile Subscriber Integrated Services Digital Network) from an internal or external MTC Server.
In 3GPP Release 11, the external identifier was defined to replace MSISDN (as described in [2]) for PS (packet switched) only devices (e.g. dongles, M2M (machine-to-machine devices). This was to overcome the shortage of MSISDN (E.164 numbers). If M2M demand forecast grows over 200 million connections by 2013 and perhaps as high as 40 billion by 2020, then the geographic numbers are in short supply especially in certain rate centers. In the US alone, it may cost around $100+ billion to move to 12+ digit numbers. Thus the need to introduce a new internet type identifier (NAI (Network Access Identifier), FQDN (Fully-Qualified Domain Name), URI (Uniform Resource Identifier)) for PS only devices was seen as urgent. 3GPP Release 11 agreed to define NAI.
Traditionally, these identifiers (MSISDN and now external identifiers) are expected to be provisioned offline by the operators in the subscription database and assigned to the subscribers at the time of subscription. Provisioning external identifiers for millions of devices manually (especially when a single service provider subscribes for numerous devices, i.e. nationwide customers for an electricity company) becomes a labor intensive process, not to mention the associated cost and human errors that are associated with it. This calls for the need to consider other provisioning methods that can be automated in the system.
If some automated applications running in the device need external identifiers, then it needs to be provided offline. If such devices are deployed in remote areas, then again it increases the manual administrative cost of provisioning external identifiers.
For a low ARPU (Average Revenue per User) M2M business, manual provisioning of external identifiers may not be cost effective. Furthermore, as per Release 11, each application running in the device could be assigned a different external identifier (as described in [2]). From MNO's (Mobile Network Operators) perspective, manually provisioning external identifiers for millions of devices (many for each device) could be cost prohibitive and not justified, thus the need for a solution to provision them automatically is warranted.
Currently, 3GPP specifies the properties of an external identifier (e.g., LocalIdentifier@domainIdentifier) but 3GPP does not specify how the external identifiers are provisioned in the HSS (Home Subscriber Server) and provided to the user. Provisioning is assumed to be done offline and manually by MNO. As per solution specified for Release 11, it is not required by the network to send it to the device. Thus there is no known solution to automate provisioning of external identifiers in the HSS and in the device.